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A SYSTEM AND METHOD FOR USING AN INTELLIGENT 
PERIPHERAL TO SUPPLY TELEPHONE SERVICE 

FIELD OF THE INVENTION 

The present invention relates to using an Intelligent Peripheral in a network. In 
particular, the present invention relates to systems and methods for using applications and 
features that are driven by an Intelligent Peripheral in a telephone-network environment. 

BACKGROUND 

Intelligent Peripherals (IP) are devices that perform services such as playing an 
announcement, collecting digits, recognizing voice commands, converting text to speech, 
recording and deleting a user-specific announcement, and verifying digits, for example, for 
callers who connect to a network through a switch. IP's can have bearer and signaling 
communication paths to switches, and have signaling communication paths to databases. 
Figure 1 is an example of how an IP might be configured within a network. In this figure, IP 
101 is connected to switch 102 via a signaling and bearer connection. Switch 102 is 
connected to database 103 via a signaling connection. The signaling connection can, for 
example, be part of the GR1 129 protocol. Calling party 104 can dial a telephone number. 
This can result in a call-request received by switch 102, which can then signal database 103 
with information about the caller. If database 103 determines that certain services are 
required (e.g., play announcement and collect caller digits), then database 103 can contact IP 
101, via switch 102, asking IP 101 to perform the services. For example, the database can 
cause the IP to perform its particular function. 

The capabilities of this embodiment are limited in that the switch and IP must use the 
same protocol (typically, the GR1 129 and the GR1299 protocol). Additionally, in this 
embodiment, database 103 can only talk to IP 101 through switch 102, unnecessarily tying up 
switch 102. 

Figure 2 is another example of how an IP might be configured within a network. In 
this figure, IP 201 is connected to switch 202 for connection control only, but is connected 
directly to database 203 via a signaling connection for service control. The features of this 
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embodiment are extremely limited, however, because a switch that uses the ITU-T protocol 
can not be an advanced intelligent network (AUM) switch. Thus, the services offered by the 
embodiment in Figure 2 are limited to ITU-T services. 

Regardless of the protocols used, it is thought that network performance might be 
improved if the IP-database-switch interaction were implemented in a way that is 
substantially protocol independent, and in a way that allows for direct communication 
between various components. 

SUMMARY OF THE INVENTION 

To alleviate the shortcomings in known systems, an embodiment of the present 
invention provides EP-database-switch interaction in a substantially protocol-independent 
way, while allowing for direct communication between the DP and the database. 

In one embodiment of the present invention, a method provides communication 
service in an Advanced Intelligent Network environment, the communication service utilizing 
at least a database, an AIN switch and an intelligent peripheral (IP). An alert message is sent 
from the database to the IP. The alert message includes a parameter identifying an arbitrary 
protocol that is used for the IP and the database to communicate. The IP can have the ability 
to understand multiple protocols so that the AIN switch, the database and the IP can 
communicate in an efficient and flexible way. Once the IP is contacted, and a protocol is 
decided upon, the IP can establish a bearer connection with-the switch. The IP can then 
receive instructions from the database to perform a service. Alternatively, the database and IP 
can send and receive instructions to perform the service prior to creating the bearer 
connection. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is an overview of a known system featuring an intelligent peripheral, a 
switch, a network and a database. 

Figure 2 is another overview of a known system featuring an intelligent peripheral, a 
switch, a network and a database. 

Figure 3 is a system overview of an embodiment of the present invention having an 
intelligent peripheral, an advanced intelligent network switch and a database. 
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Figure 4 is a data flow diagram of an embodiment of the present invention in which a 
database and an intelligent peripheral interact. 

Figure 5 is a flow chart depicting a method embodiment of the present invention. 

Figure 6 is a block diagram of an apparatus according to an embodiment of the present 
invention featuring a processor, a port and a memory. 

DETAILED DESCRIPTION 

The present invention relates to systems and methods for performing telephony 
services. In particular, the present invention relates to using an advanced-intelligent-network 
(AIN) switch with a database and an intelligent peripheral (BP) in a way that is not limited by 
protocol constraints. 

Figure 3 is a system overview of an embodiment of the present invention. In this 
embodiment, AIN switch 302 can receive a call from party 304. AIN switch can also, via 
signaling network 305, send signaling messages to and receive signaling messages from 
database 303. Additionally, AIN switch 302 can send information to and receive information 
from IP 301. 

Database 303 can send signaling messages to and receive signaling messages from 
AIN switch 302. Additionally, database 303 can send signaling messages to and receive 
signaling messages from IP 301, again via signaling network 305. 

Finally, IP 301 can send information to and receive information from AIN switch 302, 
and can send signaling messages to and receive signaling messages from database 303. The 
interaction between IP 301 and AIN switch 302 can be via any combination of signaling and 
bearer connections. 

As a contextual example, and still referring to Figure 3, assume party 304 places a call 
that is routed through AIN switch 302. When AIN switch 302 receives the call, switch 302 
sends information to database 303 regarding the call. Database 303 can then, using the 
received information, determine whether services are to be performed for that caller, and if 
so, what those services are. 

Once database 303 determines the services to be performed, database 303 contacts IP 
301 to request the IP to perform the service. The data flow between database 303 and IP 301 
typically begins with an alert message, shown in Figure 4 as step 401 . This alert message can 
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contain information as to what protocol database 303 will use to interact with IP 301. IP 301 
is protocol independent in the sense that, once database 303 informs it which protocol is to be 
used, IP 301 can use and understand that protocol. 

At step 402, IP 301 can respond to the alert message, acknowledging receipt. At step 
403, a signaling message is sent to AIN switch 302, informing switch 302 that it should 
connect with IP 301. Switch 302 can then send a setup signaling message to IP 301, 
requesting that IP 301 establish a bearer connection with switch 302. IP 301 then, based on 
this prompt from switch 302, establishes the bearer connection by sending a connect- 
signaling message to the AIN switch (step 403). 

In the above embodiment, IP 301 establishes a bearer connection based on a prompt 
by switch 302. Alternatively, IP 301 can create a bearer connection without prompting from 
the switch. The establishment of the bearer connection can be based on information received 
from database 303. 

At step 404, a message is sent from IP 301 to database 302 informing database 302 
that a bearer connection has been established with switch 302. Then, at step 405, database 
303 sends IP 301 a message requesting that IP 301 perform a task or tasks that make up the 
service. Once the task or tasks are performed, the database is informed at step 406, and the 
connection is closed between the database and the IP. This task-complete message is 
acknowledged at step 407. At step 408, IP 301 can then close the bearer connection with 
switch 302, and switch 302 can send a "resource clear" message to database 303. 

Figure 5 is a flow chart depicting a method according to an embodiment of the present 
invention. This embodiment is described from the perspective of the DP. It should be noted 
that the order in the flow chart is not meant to imply an explicit order to the steps; the steps of 
the method embodiments can be performed in any order that is practicable. 

At step 501, the IP receives an alert message that includes a protocol parameter. The 
protocol parameter identifies the message as being sent from a database that uses a specific 
and known protocol. The IP has previously stored software modules that can be used to 
interact with the database; each software module includes instructions to interact with the 
database in a specific protocol. Each software module is stored in a database in the IP and 
correlated with a stored protocol parameter. Thus, when the IP receives from a database an 
alert message that includes a specific protocol parameter, the IP can select, using the 
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database, the proper software module to interact with the database. For example, if the 
database requires interaction with the IP using the ITU-T protocol, the alert message sent by 
the database will include a parameter that allows the IP to understand that it is to use the ITU- 
T protocol in its interactions with the database. Thus, at step 502, a software component that 
correlates with the protocol parameter is identified. The IP can respond to the alert message 
by sending an acknowledgment signal. 

At step 503, the software component is executed. That is, the IP is initialized to 
receive instructions from, and to report to, the database, using the desired protocol. Examples 
of some known protocols include SR351 1 and ITU-T CS2 SRF-SCF operations. 

At step 504, a first bearer connection is established with an AIN switch. At step 505, 
the IP receives instructions from the database to perform a service. In one embodiment of the 
present invention, the instructions are sent from the database directly to the IP. In another 
embodiment of the present invention, the instructions are sent to the IP via the AIN switch. 

The IP can interact with the AIN switch using any known protocol. For example, the 
IP can interact with the AIN switch using existing GR1 129 procedures. In one embodiment 
of the present invention, the AIN switch can prompt the IP to establish the bearer connection. 
The AIN switch can first send a setup-signaling message containing a correlation ID 
parameter. The IP then can send a connect-signaling message to establish a bearer 
connection. The IP can correlate the bearer connection to the signaling connection between 
the database and the IP by matching the correlation the ID parameter received in the setup 
signaling message from the AIN switch and the correlation ID parameter received from the 
database. 

In another embodiment of the present invention, the IP can request establishment of 
the bearer connection unprompted, or prompted by the database. This bearer connection can 
be to a new party (this is equivalent to the IP dialing a new number) or the IP can request the 
AIN switch to bridge the bearer connection to the original party. The AIN switch is capable 
of bridging based on certain information such as a circuit identification code parameter 
received in a signaling message from the IP. Once the service is performed, then at step 506, 
the IP sends to the database the results of the performed service. 

The services performed by the IP can include, but are not limited to, playing an 
announcement, collecting dual-toned multi-frequency (DTMF) signals, cancel playing an 
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existing announcement, disconnecting the call, voice recognition, text-to-speech analyzing, 
collecting digits against a set of criteria or rules. It should be appreciated that, in known 
systems, the database would have to send distinct instruction packets to (I) request that a task 
be performed, (ii) cancel performance of the task, and (iii) perform a new task. In 
embodiments of the present invention, however, these distinct instructions can be merged into 
one package or message from the database to the IP. For example, in known systems, the 
database would have to send to the IP three distinct instruction packets to (I) cancel the 
performance of an ongoing task, (ii) perform a new task, and (iii) disconnect the call. In 
embodiments of the present invention, however, the IP can receive these three instructions in 
one package or message, and the IP has the intelligence to perform the service. 

The IP can receive and perform any number of services. For example, the IP can 
receive, in one package or message, instructions to play a plurality of announcements, at least 
two of which will require the calling party to input DTMF signals. In response, the IP can 
send to the database, in a single package or message, multiple sets of collected DTMF signals 
from a calling party. 

In addition to receiving and forwarding DTMF signals, the IP can analyze the DTMF 
signals based on rules received from the database. For example, assume the IP is to collect a 
ten-digit DTMF signal with the proviso that the caller not input "900" in the first 3 digits. If 
the caller does, in fact, input "900" as a DTMF signal, the IP can realize this and take an 
action such as, but not limited to, playing an error announcement or disconnecting the call. 
Likewise, the IP can receive an instruction from the database to play an announcement a 
predetermined number of times, or to play an announcement until a DTMF signal is received. 

In one embodiment of the present invention, once a bearer connection is established 
between the IP and the AIN switch, the IP can create a plurality of second bearer connections 
with the switch based on instructions from the database. In this embodiment, the IP initiates a 
call-setup message to the AIN switch, and the calls are bridged through the IP to create a 
conference call. In one embodiment, a connection can be made to a IP peripheral for a first 
subset of the parties in an active multiparty call, and a bearer connection can be made to a 
second IP for a second subset of the parties in an active multiparty call. 

The IP can receive instructions from the database such that, once the plurality of calls 
are bridged through the IP, the IP can perform a task or service for the first party, and perform 
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a task or service for a second party who is part of the plurality of calls. The results of these 
performed services can be reported to the database. Once the IP has performed its services or 
tasks, it can pass the calls back to the switch and drop the bearer connection, freeing up the IP 
for other uses. 

In one embodiment, while a multiparty call is in an active stage, the database can send 
to the AIN switch instructions in one package to cause the AIN switch to request 
establishment of bearer connections to different IPs for different subsets of the parties in the 
call. 

Figure 6 is a block diagram of an apparatus embodiment of the present invention. In 
one embodiment, the apparatus includes processor 601, port 602 coupled to processor 601, 
and memory 603, also coupled to processor 601. Memory 603 can store instructions adapted 
to be executed by processor 601 to perform any method embodiment of the present invention. 
For example, memory 603 can store instructions adapted to be executed by a processor to 
receive an alert message that contains a protocol parameter, identify a protocol that correlates 
with the protocol parameter, and then execute the protocol. 

For the purposes of this application, memory includes any medium capable of storing 
instructions adapted to be executed by a processor. Some examples of such media include, 
but are not limited to, RAM, ROM, floppy disks, CDROM, magnetic tape, hard drives, 
optical storage units, and any other device that can store digital information. In one 
embodiment, the instructions are stored on the medium in a compressed and/or encrypted 
format. As used herein, the phrase "adapted to be executed by a processor" is meant to 
encompass instructions stored in a compressed and/or encrypted format, as well as 
instructions that have to be compiled or installed by an installer before being executed by the 
processor. 

The present invention has been described in terms of several embodiments solely for 
the purpose of illustration. Persons skilled in the art will recognize from this description that 
the invention is not limited to the embodiments described, but may be practiced with 
modifications and alterations limited only by the spirit and scope of the appended claims. 
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